home *** CD-ROM | disk | FTP | other *** search
/ Fritz: All Fritz / All Fritz.zip / All Fritz / FILES / EDUCICAL / LIFE050.LZH / README.050 < prev    next >
Text File  |  1986-12-25  |  13KB  |  232 lines
  1. Notes on TurboLife version 0.50 (12/25/86) (PLEASE READ THESE!):
  2.  
  3. To contact me
  4. =============
  5.   Direct all problem reports, suggestions, complaints, cash donations etc. to
  6. Bela Lubkin via USnail, Ma Bell, CompuServe or local BBS.  My various addresses
  7. and numbers are:
  8.  
  9. USnail:
  10.   Bela Lubkin
  11.   406 Murray Ave.
  12.   Aptos, CA  95003
  13.  
  14. Ma Bell:
  15.   (408) 662-0535 (voice)
  16.  
  17. CompuServe:
  18.   73047,1112 (EasyPlex)
  19.  
  20. Local BBS (Santa Cruz, CA):
  21.   "Filbo" on Pyrzqxgl, (408) 336-3134 (Zend mail)
  22.  
  23. PLEASE CONTACT ME IF YOU FIND A BUG OR WANT TO SUGGEST A FEATURE!!!!  Apathy
  24. sucks!!!
  25.  
  26. What has changed since version 0.39
  27. ===================================
  28.   Most importantly, I converted the innermost loop of the generation routine
  29. from Turbo Pascal to assembly language.  The first step was a straightforward
  30. port to assembly language, making use of registers as much as possible.  This
  31. resulted in a 3-to-1 speedup.  Next, I modified the algorithm in certain ways,
  32. and "bummed" the code as much as possible.  This brought the speedup to about
  33. 4-to-1.  Finally, I ran into a program called FASTLIFE on a local BBS.  It had
  34. radically different performance characteristics: it was much faster for densely
  35. packed action, but much slower for sparse areas.  I spoke to the author, Dan
  36. McMullen, and got some extremely useful ideas.  I had been dealing with a bit
  37. at a time, in registers; I now deal with a byte at a time, as much as possible.
  38. This brings the total speedup to 5.5-to-1 for the simplest figures, and an
  39. amazing 16-to-1 for densely packed action.  My benchmark suite, which has a
  40. great deal of variety in its tests, shows an overall speedup of 6.45 times.
  41. Mileage may vary <grin>.  My heartfelt thanks to Dan!
  42.  
  43.   Other changes include:
  44.     o Directory window: when saving or loading a file, if you give a wildcard
  45.       filename such as *.LIF, a directory window pops up and you can select the
  46.       desired file interactively.  The directory window is fully aware of the
  47.       DOS 2.0 directory structure, and will let you walk about different
  48.       directories.
  49.     o Overwrite protection: you are asked before TurboLife will overwrite an
  50.       existing file.
  51.     o The Undo command will undo one Go, single step or Load command.  If Undo
  52.       does not appear on your main menu, you don't have enough memory for it;
  53.       you will need up to 32K more than you need to be able to run TurboLife at
  54.       all, depending on your video board.  Total memory needs range from about
  55.       105K on a CGA (Undo disabled) to about 220K on a VEGA Deluxe in 640x480
  56.       resolution (Undo enabled).
  57.     o Mutations: when mutations are enabled, a single, randomly chosen pixel
  58.       may be changed in any particular generation.  How often this occurs is
  59.       settable, anywhere from every generation to once per thousand
  60.       generations.
  61.     o Support for more graphics hardware:
  62.         EGA with mono or ECD monitor (640x350)
  63.         Olivetti M24/AT&T 6300/Xerox 6030 (640x400)
  64.         Toshiba T3100 (640x400)                                (-experimental-)
  65.         Video-7 VEGA Deluxe/QuadRAM QuadEGA Prosync (640x480)  (-experimental-)
  66.       Any reports on the Toshiba T3100 and the VEGA/QuadRAM cards will be
  67.       appreciated.
  68.     o On graphics hardware with several resolutions available, you can choose
  69.       which resolution to use.  This may be useful for looking at saved figures
  70.       which make use of wrap effects.  FACTORY.LIF is an example of such a
  71.       figure: it is interesting on any board, but particularly amazing at a
  72.       resolution of 640x200.
  73.     o When a file is loaded which was saved on lower resolution graphics
  74.       hardware, a check is made to see whether any features of the saved figure
  75.       were meant to wrap around the edges of the screen.  If the first and last
  76.       lines of the saved image are found to be identical, the additional lines
  77.       of the screen are filled with copies of that same line.  The same is done
  78.       for the first and last columns of the saved figure.  This means that, for
  79.       instance, "great circle" images saved on the CGA can be loaded on an EGA,
  80.       at 640x350 resolution, without losing their continuity.
  81.     o More stringent checking is done when files are loaded to ensure that only
  82.       valid files are loaded.  (In particular, using the wrong function to load
  83.       a .RUL or .LIF file will no longer appear to work while actually
  84.       failing).
  85.     o The rule "a dead pixel with no neighbors springs to life" may now be
  86.       declared.
  87.     o When changing rules, the entire screen is considered under the new rules,
  88.       not just the points that had been active under the old rules.
  89.     o File load/save status messages now stay on screen for 5 seconds or until
  90.       a key is pressed.  These delays now work properly on the Tandy 2000.
  91.     o Save files are now 1/2 as large as before.
  92.     o WordStar key sequences are supported everywhere that keypad keys work;
  93.       keypad keys do not require NumLock to be turned off, except the "5" key,
  94.       used in the Rule editor.  Why IBM chose to make that key generate no data
  95.       is beyond me...
  96.     o Many bugs have been fixed.
  97.     o Probably more that I forget.  It's been a year!
  98.  
  99. "Flicker between the graphics and text areas"
  100. =============================================
  101.   If you see a rapidly flickering point just to the right of the playing field
  102. (to the left of the menu and other text), good!  You're supposed to.  While the
  103. generation algorithm is thinking about a single line of the screen, it turns on
  104. a point at the right of that line to show its progress.  This was put in the
  105. program when it was more than 20 times as slow as it is now, and I was using an
  106. 8088 machine with 640x400 resolution, to boot.  While waiting up to a minute
  107. for a generation to complete, it was good to have some indication that the
  108. program hadn't crashed yet.  I've left the indicator in because it acts as sort
  109. of a "heartbeat meter", giving you an at-a-glance idea of how fast the program
  110. is moving at the time.  You can gain some insight into how the program works by
  111. observing the indicator while playing with complicated figures.  For instance,
  112. draw a line all the way across the screen horizontally.  Turn wrap on, Go, and
  113. watch the indicator.
  114.  
  115. What's in the distribution ARC file
  116. ===================================
  117.   The distribution ARC file contains this file (README.050), LIFE050.COM, and
  118. DEMOS.ARC (a nested ARC file).  DEMOS.ARC expands to about 175K, so be
  119. prepared.  Inside DEMOS.ARC are a number of rule sets and figures; unless
  120. otherwise noted, all rule sets and figures, and their names, are my own.
  121.  
  122. The rule sets are as follows:
  123.   LIFE.RUL - standard Life rules (John Horton Conway)
  124.   3-4LIFE.RUL - 3-4 Life, as defined in "The Recursive Universe" (TRU)
  125.   FREDKIN.RUL - Fredkin's Game (TRU).  Anything you enter is duplicated
  126.   CRYSTALS.RUL - Homebrewed set of rules that make pretty crystals
  127.   A.RUL - Slightly modified normal Life, has some interesting patterns
  128.   FIRE.RUL - interesting rules that generate fire-like patterns -- try a
  129.              vertical or horizontal bar, for instance
  130.   LACE.RUL - makes lace-like patterns
  131.   DOWN.RUL - inspired by Graeme McRae.  Any figure simply moves down the screen
  132.   DOWNGROW.RUL - modified DOWN.RUL, sends interesting streamers down the screen
  133.   OOZE1.RUL through OOZE4.RUL - four variations on a theme: rules that... ooze!
  134.  
  135. The figures are as follows:
  136.   3WAY.LIF - An engineered 3 way collision
  137.   R5OMINO.LIF - The famous R Pentomino (TRU).  1103 generations to completion
  138.   OSCILLAE.LIF - An assortment of oscillators from TRU.  Left to right, they
  139.                  are: Toad, Beacon, Clock, Pulsar, Figure 8, Pentadecathlon,
  140.                  Barber Pole, Flip-flop, Galaxy, Tumbler, Clock II, stabilized
  141.                  Shuttle, B Heptomino Shuttle, Glider, Lightweight,
  142.                  Middleweight and Heavyweight spaceships
  143.   FLOTILLA.LIF - An overweight spaceship with flotilla escort (TRU)
  144.   ACORN.LIF - Another long messy figure, this one goes for 5206 generations
  145.               before stabilizing (TRU)
  146.   GLIDRGUN.LIF - A glider gun (TRU).  Includes an Eater (TRU) to consume the
  147.                  gun's output
  148.   MAKEGGUN.LIF - "Thirteen gliders collide to form a glider gun" (TRU)
  149.   NEWGUN.LIF - "New gun", a different flavor of glider gun.  (TRU)
  150.   MACHNGUN.LIF - A "machine gun" made out of multiple concatenated glider guns
  151.   FACTORY.LIF - A glider factory made out of cooperating glider guns
  152.   PUFTRAIN.LIF - Puffer train.  Given enough screen space, this eventually
  153.                  stabilizes (becomes periodic), generating an ever-
  154.                  lengthening tail of debris.  Stabilization occurs at
  155.                  generation 5533, but there is not enough screen space on
  156.                  any TurboLife-supported video board to see more than a hint
  157.                  of the stabilization.  (2800 pixels horizontal would be
  158.                  necessary to carry it out to full stabilization).  (TRU)
  159.   OSCILLAE.3-4 - A bunch of oscillators from 3-4 Life (load the 3-4 Life rules
  160.                  first -- these won't do much under normal Life rules).  Around
  161.                  the outside, clockwise, ignoring duplicates, are: Ward
  162.                  Christensen's object (I'll let him name it!), Broken T (TRU),
  163.                  Bleeper (TRU), Frog, T (TRU), and Y.  On the next row in are:
  164.                  3-4 Spaceship (TRU), 3-4 Clock (TRU), Shaker, Broken 3-4
  165.                  Clock.  In the center are a Bullfrog and a Twombler
  166.   YOW.CRY - an interesting initial pattern for the rule set "Crystals".  It is
  167.             saved with mutations enabled, set at a low rate; you may also want
  168.             to run it with mutations disabled entirely
  169.   T-BARS.3-4 - a very interesting scenario for 3-4 Life
  170.   MOREBARS.3-4 - similar to T-BARS.3-4
  171.   CREATION.OOZ - let there be ooze!
  172.  
  173. Adding support for additional video boards
  174. ==========================================
  175.   I am continually on the lookout for more video boards to add support for.
  176. If you have a video board which does something beyond the standard IBM
  177. 640x200 mode, give me information on it and I'll try to support it.  Each
  178. added board costs me something like 100 bytes of code, so I am not even going
  179. to start worrying about it yet.
  180.  
  181.   What I need to know: I access the video memory of the board directly.  The
  182. memory layout must be similar to the CGA's in that each scan line must
  183. consist of contiguous bytes, each byte containing 8 pixels, the high bit being
  184. the leftmost displayed bit.  Therefore, in order to plot, all I need to know
  185. is the formula for the address of a scan line, given its vertical coordinate.
  186. Thus for the CGA, BaseAddress(Y)=2000h*(Y AND 1) + 80*(Y DIV 2).  Other than
  187. that, I must have the following information: the resolution; how to turn this
  188. mode on; how to turn it off; how to generate text, if not through standard
  189. BIOS writes; and most importantly, how to detect that a machine has this
  190. capability.  I may end up forced to add a manual install-for-video-board
  191. routine to the program, but I will not if I can possibly help it.  Additional
  192. information that would be useful: how to modify the foreground and background
  193. colors, if applicable.  Note that in all cases I'm interested in the highest
  194. possible resolution of the card, and that in fact my code cannot support
  195. multicolor modes like the CGA's 320x200; it can support multiplane setups
  196. like EGA mono, but only by ignoring all but one plane.  Thus it may be
  197. necessary to diddle palette registers to make a single plane look good.
  198.  
  199. Sigma SR400!
  200. ============
  201.   IN PARTICULAR, I am all ready to support the Sigma SR400 board, with 640x400
  202. resolution, but I do not know how to detect this board at runtime.  The
  203. detection method must be unambiguous.  If you have an SR400, or have any
  204. information on it, please let me know!
  205.  
  206. Thanks
  207. ======
  208.   I want to thank John Conway for inventing Life; Piers Anthony and Martin
  209. Gardner for making me aware of it; Dan McMullen for helping me refine my
  210. generation algorithms; Kim Kokkonnen, Neil J. Rubenking, Doug Hogarth, Dave
  211. Hoagland, Don Watkins, Joan Friedman, Grame McRae, Joe Kyle and many others for
  212. helping me test the latest versions; and most especially the dozens of people
  213. who have made comments and suggestions about the program even when I wasn't
  214. actively soliciting responses.
  215.  
  216.   Believe me, I >like< getting suggestions and even bug reports.  Easy
  217. suggestions may get implemented right away; bug reports will be dealt with as
  218. quickly as possible.  Even if I don't take you up on your suggestion, I
  219. appreciate knowing that you're out there and have enjoyed using my program.
  220.  
  221.   By the way, one suggestion that I am not going to take up is that of using
  222. color as another dimension of the program.  I may eventually support the
  223. ability to set the foreground and background colors of the playing screen, for
  224. esthetics; I will not support color as an active part of the game.  It slows
  225. things down, and the uses I've seen for color in Life games have seemed
  226. contrived at best.
  227.  
  228.   Any input appreciated.
  229.  
  230.   -  Bela Lubkin
  231.      December 25, 1986
  232.